The present invention relates to supervision timers that alert a client that a server has not responded within an expected response time period, and more particularly to mechanisms for deriving suitable supervision timer values to be used in supervision timers.
Today, there exist various scheduling algorithms in computer/telecommunication science dealing with system resource sharing between various data flows and processes in multi-tasking/multi-dataflow systems. The aim of all these scheduling algorithms (e.g. Round-Robin, Weighted Fair Queue, Fair Queue, Priority Inversion and so on) is to allow all services/tasks/processes/data flows to share common resource time, avoid starvation, and produce an acceptable average throughput to the overall system.
If several services competing for the very same resources need to be performed simultaneously, the very lowest layer (i.e., the Physical Layer 1, PHY) utilizes some mechanism that resolves the conflict by prioritizing the requests in a manner such that a higher priority service will be awarded access to the shared resource before the lower priority service is. This is the case regardless of whether the priorities are static in nature or are dynamically adapted to a changing environment.
In many software and/or hardware systems with distributed functionality amongst the various entities, responsibility is divided between the aforementioned entities by defining a client-server relationship between the entities. A client makes a server request, and the server at some point in time, responds to that request.
Once it has made a request, it is the client's role to wait for a response. The question then arises how long should the client wait for a response? If something were to go wrong at the server side causing it never to respond, the client could end up waiting forever. In order to avoid such behavior, a client will want some means for monitoring the activity of the server. Such monitoring could, for example, be accomplished by means of a supervision timer when the client knows the expected response time for a certain service. The client starts the supervision timer when it makes a server request. In case, for some reason, the server is not going to respond, the client's supervision timer will time out which then alerts the client to take actions accordingly.
The idea of a client supervising a server and taking proper actions in cases when the server is not responding when it should, adds quality to the experience of the end-user. In a consumer product, the client could, for example, restart the server and hide the fact that the system was hanging. In other contexts, such as in a safety-related system, the end-user could be informed of the server's failure to respond so that the end-user can take proper actions.
A problem emerges for a designer of such a system when setting/designing these supervision timers. This is especially true if the system is lacking a proper/strict time requirement for every single service designed in the system. This might not be a problem in a strict real-time system with strict requirements used in, for example, an airplane, but in most consumer products (e.g., mobile handsets) such requirements are lacking. Consider for example, a situation such as that depicted in the block diagram of FIG. 1. Here there are four services, denoted Svc1, Svc2, Svc3, and Svc4, which are capable of being run in a device 101. Each of the services has been divided into client and server portions. The clients and corresponding servers of services Svc1, Svc2, Svc3 are all located within the device 101, whereas only the client portion of Svc4 is implemented within the device 101. In the latter case, Svc4's server requests are sent to an external server 107 by means of some communication means.
The services are variously implemented in whole or in part by means of the same shared processor/circuit elements 103 and (possibly) a memory device 105. To better illustrate the example, the various services are shown as being separate from the shared processor/circuitry 103 and memory device 105. In some implementations, it may actually be the case that one or more of the services have dedicated hardware elements, separate and apart from the shared processor/circuitry 103. However, it may also be the case that any or all of the services are implemented entirely by the shared processor/circuitry 103 and memory device 105 (e.g., by means of program instructions stored in the memory device 105 that are intended for execution by the shared processor/circuitry 103). Regardless of implementation, however, the services are implemented separate and apart from one another and are individually activated.
The inventor has appreciated that if the services Svc1, Svc2, Svc3, and Svc4 were implemented independently of one another, a supervision timer value could be derived for each one by measuring the average latency between the server request and the corresponding response. However, the services Svc1, Svc2, Svc3, and Svc4 are not independent of one another, but instead share the shared processor/circuitry 103 and memory 105. Consequently, for any given one of the services Svc1, Svc2, Svc3, and Svc4, the latency between a server request and the corresponding response will depend on how much access that service has to the shared resource. If it is the only service that has been activated (which means it has exclusive use of the shared processor/circuitry 103), the measured latency will be at its lowest value. However, the more services there are that are run concurrently, the less access each one of the running services has to the shared processor/circuitry 103. This slows things down generally, and measured latencies between service requests and their corresponding responses will increase.
Designers try their best to tune supervision timer values as part of the process of designing the device, but there are many problems to deal with. Some of these problems are:                Timers are often tuned in a lab environment that does not reflect real scenarios.        Even if an effort is made to tune supervision timer values in some real scenario, it is almost impossible to foresee all different scenarios involving speed, landscape, operator network planning, and the like. The inventor has recognized that these factors affect which services are (possibly simultaneously) active in a mobile communications device, and this in turn affects the expected latency between a client request and its corresponding server response.        The inventor has recognized that it is almost impossible to foresee the dynamic behavior and the interaction of all possible services used by the end-user. As a result, apart from a few scenarios, services are often tested, one service at a time, in a lab. As explained above, there is a major difference in letting one service run with full access to all resources, and letting several services run concurrently, fighting for the same resources.        The systems are becoming more and more complex (e.g., a multi mode mobile handset with ability to provide services in accordance with different communication standards such as, but not limited to, Global System for Mobile communication (GSM), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), Wireless Local Area Network (WLAN), and the like) but little time is left in a time restricted project for re-tuning the old timers.        The very same timer values stored in one software database (perhaps some number of years earlier) are retained and used in a current implementation. Even if the timer values were optimal at the time they were determined, but the product evolves in terms of:                    New features being added            Some features being removed            Some earlier algorithms being optimized in a later phase            New hardware being more powerful and faster.            The same software database being used in various hardware databases (low-end/high-end) with completely different capabilities                        
As a result of the problems mentioned above, designers tend to set supervision timer values to unnecessarily high values in order to ensure that, whatever the operational environment, the supervision timer will not timeout prematurely, leading to a poor user experience. However, a consequence of this is that an actual server failure to respond to a client request will be detected long after it could have been.
It is therefore desired to provide better supervision timer control mechanisms that address one or more of the above-described problems.